\chapter{Information Viewpoint}
\label{cap:InformationViewpoint} 


\section{Database and data Design}

In order to handle persistent data, we realized a relational database. In this section we are about to describe the conceptual design of the database that to say we'll introduce its relational model and its logical schema.
We'll proceed in two different steps: former we presents the entity relational model and we'll discuss all its parts,latter we present the logical model and thus all the table we need to work with our data.

\section{Conceptual Design}

Here we are about to show and comment the ER diagram. An ER diagram represents the conceptual organization of the data that to say all entity are represented and taken in relation to each other according to the application logic. The figure below shows the diagram we designed:

\begin{figure}[htbp]
	\centering
	\includegraphics[scale = 0.25]{images/SWIMv2-ER.png}
	\caption{J2EE architecture\label{fig:architecture}}
\end{figure} 



\newpage

\subsection{Entities Description}
Now we are about to describe every entityes and relations shown in the diagram above.

\begin{description}


  \item[User] \hfil \\
	This entity represent both who made a registration and who have to confirm it.
  
  \item[RegisteredUser] \hfill \\
	This entity describes a registered user of the database and keeps track of his vital statistics.
  	 
 \item[Admin] \hfill \\
  	This entity describes an admin user of the database. He's a generalization of a Registered User.
  	We also store the date of his "election" to admin.
  	
  \item[Founder] \hfill \\
  	This entity describes the founder user of the database. He's a generalization of  Admin.
  	 
  \item[ToConfirmUser] \hfill \\
  	This entity is only used to handle the e-mail based registration, we store all the data specified in the registration form and also two extra fields: a validation string used as e-mail check code and the date until the validation should be possible.
  
  \item[BannedUser] \hfill \\
	This entity describes a banned user of the database, he's a generalization of a Registered User.
  	We also store the date of the end of his ban.
  
  \item[HelpRequest] \hfill \\
  This entity describes a request for help from a registered user to another. It has a little description (summary) and dates to show the period in which is alive
  
  \item[PrivateMessage] \hfill \\
  This entity describes a private message sent from a user to a registered user.
  
  \item[Ability] \hfill \\
  This entity describe a ability that one or generally more users have.
  
   \item[Feedback] \hfill \\
	This entity describes a feedback left from a registered user to another registered user.
	The first user has to have helped the second after a request for help by the second.
  
\end{description}


\subsection{Relationship Description}

\begin{description}

	\item[Ask] \hfill \\
	 A Registered user can Ask for help.
	 
	 \item[Answer] \hfill \\
	 A Registered user can Answer a  help request.
	 
	 	\item[Friend] \hfill \\
	 A Registered user can have many friends
	 
	 	\item[Has] \hfill \\
	 A Registered user can have many abilities.
	 
	 	\item[Leave] \hfill \\
	 A Registered user can Leave many feedbacks.
	 
	 	\item[Get] \hfill \\
	 A Registered user can Get for help.
	 
	  	\item[Send] \hfill \\
	 A Registered User can Send a Private Message
	 
	 	\item[Receive] \hfill \\
	 A Registered user can Receive a Private Message

  
\end{description}




\section{Logical Schema}


\begin{itemize}
 
 \item RegisteredUser (\uline{username}, password, email, birthday, name, surname, address, sex, image, isPublic)
 \item Admin (\uline{username}, password, email, birthday, name, surname, address, sex, isPublic, tookover)
 \item Founder (\uline{username}, password, email, birthday, name, surname, address, sex, isPublic, tookover) 
 \item BannedUser (\uline{username}, password, email, birthday, name, surname, address, sex, endofban)
 \item ToConfirmUser (\uline{username}, password, email, birthday, name, surname, address, sex, activationCode, validUntil)
 \item Friendship (\uline{username1, username2}, direct)
 \item FriendshipRequest (\uline{applicantName, requestedName}, direct, refused)
 \item HelpRequest (\uline{id, askingUser, answeringUser}, title, summary, creationDate, endDate, accepted)
 \item PrivateMessage (\uline{id}, object, text, sentBy, senderUsername)
 \item ReceivedMessages (\uline{messageID, recipient}, messageRead)
 \item Ability (\uline{name}, alreadSeen, confirmed, description)
 \item HaveAbilities (\uline{username, name})
 \item Feedback (\uline{id, gotBy}, rank, text, leftBy, disputed) 
\end{itemize}


While translating the E.R. schema into Logical schema in order to realize the actual tables we derived the following bridge tables:

\begin{description}
  \item[ReceivedMessages] \hfill \\
	Derived from the many to many relation between Registered User and Messages.
   \item[HaveAbilities] \hfill \\
	Derived from the many to many relation between Registered User and Abilities
	  \item[Friendship] \hfill \\
	Derived from the many to many relation between Registered User and Registered User 


\end{description}

\section{Entity Design}

We show here the entity diagram we made in order to have a model of the system closer to the software aspect. The E.R. schema, is sure enough, close to the data-store view.
Java beans allow to represent entities with objects, and this schema, in which entities have also basic methods, fits the java beans idea.

\begin{figure}[htb]
  \begin{center}
   		\includegraphics[width=\textwidth]{images/entity}
   		\caption{Entity Diagram Schema}
  \end{center}
\end{figure}  

\subsection{Entity Description}

\begin{description}


	 
	 \item[RegisteredUser] \hfill \\
	 A Registered user, can be created, updated and searched by common fields.
	 Nevertheless we can find his abilities, his friends, his messages, his feebacks: incoming and released.	 

 \item[Admin] \hfill \\
  	This entity describes an admin user of the database. He's a generalization of a Registered User.
  	We can create and update an admin, and we find by him name or by username.
  
  \item[BannedUser] \hfill \\
	This entity describes a banned user of the database, he's a generalization of a Registered User.
  	We can create, update and remove a banned user. We can find by him name, by username or by end of ban.

  	 \item[Founder] \hfill \\
  	This entity describes the founder user of the database. He's a generalization of  Admin.  
  	We can find him by name or by username.
  
  \item[HelpRequest] \hfill \\
  This entity describes a request for help from a registered user to another. It has a little description (summary) and dates to show the period in which is alive.
  We can create a help request, and find it by title or end of validity.
  
  \item[Message] \hfill \\
  This entity describes a private message sent from a user to a registered user.
  We can find them knowing user who sent it.
  
  \item[Ability] \hfill \\
  This entity describe a ability that one or generally more users have.
  We can create, remove or update an Ability. Also we can find them by name, or list all the users who have that ability
  
   \item[Feedback] \hfill \\
	This entity describes a feedback left from a registered user to another registered user.
	The first user has to have helped the second after a request for help by the second.
	We can create update remove a feedback or list them by rank.
  
\end{description}






























